Method for supporting scalable and reliable multicast in TDMA/TDD systems using feedback suppression techniques

ABSTRACT

A method supports scalable and reliable multicast in a wireless network with a large bandwidth-delay product. In this method, acknowledgement packets from different receivers experiencing the same number of data packets lost are assigned the same time slots. This method can be combined with other loss recovery techniques, such as forward error correction (FEC) recovery, proactive protection, feedback suppression and collision detection. Scalability is achieved as bandwidth usage relates only to the number of packets transmitted, rather than the number of receivers.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to computer networks. In particular, thepresent invention relates to providing a reliable multicast servicewithout requiring the sender to check successful receipt of themulticast packet by each individual recipient.

2. Discussion of the Related Art

3GPP, 3GPP2 and WLAN systems provide multicasting services, i.e., eachsystem is capable of distributing information from a source to multiplereceivers in a multicast area using a single broadcast. Multicastingallows efficient use of scarce network resources (e.g., the airinterface) when sending the same information to multiple users.

In applications such as multimedia streaming and location-basedadvertising, receivers in a multicast group can tolerate some packetlosses. In such applications, to keep the system simple, unreliablemulticast services without loss recovery ability may be used. Tomaintain acceptable performance, the application can use upper layerreliable mechanisms (e.g., application layer forward error coding) todecrease packet loss percentage. However, for an application that is“non-fault-tolerant” (e.g., software upgrade distribution, distributedcomputing or network management which require “non fault-tolerant”information), or an application which can only tolerate a very smallpercentage of the transmitted packets to be lost, a reliable multicastservices is desired due to the fast recovery requirement.

IP and link layer protocols are the two main existing categories ofreliable multicast. IP-layer multicast protocols focus on end-to-endmulticast between heterogeneous senders and receivers interconnectedthrough the Internet. Link layer multicast protocols focus on multicastsupport between adjacent senders and receivers interconnected by acommon multi-access shared link. Until now, more research has beendevoted to IP layer multicast protocols than link layer multicastprotocols.

Current link layer multicast protocols are applicable only to local-areanetworks that has a small bandwidth-delay product and which usesstop-and-wait automatic repeat request (ARQ) mechanism to recover packetloss (e.g., 802.11 type of WLAN). Such multicast protocols are notscalable for a wireless network with a large bandwidth-delay product.Thus, there is a need for a reliable multicast protocol for a wirelessnetwork with a large bandwidth-delay product.

A reliable multicast protocol must overcome the “feedback implosionproblem” that arises as a result of the number of receivers. Thefeedback implosion problem is illustrated by FIG. 1. As shown in FIG. 1,if each multicast packet sent from a single source S1 requires anacknowledgement from each of recipients R1-R5, the number ofacknowledgement (positive or negative) packets increases as the numberof receivers. Thus, acknowledgement packets from a large number ofmulticast receivers can overwhelm the sender's processing capacity, andalso cause congestion in the sender's neighboring routers and localnetworks.

Sender-initiated protocols are typically vulnerable to the feedbackimplosion problem, as these protocols require the sender to beresponsible for reliable delivery. In such a protocol, the sender keepstracks of the acknowledgement packets received from the receivers.Further aggravating the problem are the requirements that (1) alltransmissions and retransmissions (i.e., recovery transmissions) aremulticast to all receivers, and (2) the sender continues to track thechanging set of active receivers and their reception states. Inparticular, because the IP multicast model requires a multicast datapacket to be addressed to a multicast group—thereby imposing a level ofindirection between the sender and the receivers—it may be expensive orimpossible for the sender to track the reception state of each receiver.

To circumvent the problems inherent with sender-initiated protocols,most scalable and reliable multicast protocols are receiver-initiatedprotocols, which require each receiver to be responsible for reliablepacket delivery to itself. In such a protocol, a receiver sends anegative feedback or negative acknowledgement packet (i.e., NACK packet)to the sender when a retransmission is required (e.g., when an error isdetected, a packet of an expected sequence number is not received, or atimeout occurs), and the sender is not required to maintain an updatedreceiver list. As compared to a sender-initiated protocol, areceiver-initiated protocol is generally less sensitive to the number ofreceivers receiving the multicast and results in a substantially lessernumber of feedback packets. Receiver-initiated protocols are thus morescalable than sender-initiated protocols. Nevertheless,receiver-initiated protocols are still vulnerable to a NACK-implosion atthe sender, when transmission errors are widespread at any given time,thereby resulting in a large number of NACK packets at the same time.Such a condition may occur when a resource is shared in a multicasttree, so that correlated losses among different receivers can occur. Forexample, when a packet is lost on a link to a sub-tree, each receiverdownstream from the link will experience a loss and will then respondwith negative feedback at substantially the same time.

The NACK implosion problem may be overcome by “timer-based protocols”,which assign different delays to the receivers. Under such a protocol,upon detecting a packet loss, rather than sending a NACK immediately, areceiver waits until its assigned delay expires before sending the NACKpacket. Timer-based protocols thus stagger NACK packets from differentreceivers. Ideally, one of the receivers sends out a NACK packet earlyenough in time to allow the retransmission to occur before otherreceivers send their NACK packets. Alternatively, if the NACK packet ismulticast to all receivers, other receivers may refrain from sendingtheir own NACK packets in anticipation of the retransmission responsiveto the first NACK packet. The performance of timer-based protocols thusdepends on the algorithm that assigns timeout values to the differentreceivers.

To provide scalable reliable multicast services, “structure-basedprotocols” distribute the NACK (or ACK) processing tasks to multiplenodes, so that the sender's load can be decreased. These protocolsorganize multicast receivers into different logical network structuressuch as a tree. In such an organization, a downstream node sends its ACKor NACK packets upstream to an intermediate node between it and thesender. The downstream node also receives recovery packets from theintermediate node. When the intermediate node is unable to providerecovery, the NACK or ACK packet is passed further upstream to thesender node.

An important aspect of a reliable multicast protocol is error recovery.While most reliable multicast protocols use a pure ARQ scheme to recovera packet loss, a hybrid forward error correction (FEC) and ARQ schememay substantially reduce feedback implosion and the expected delay ofpacket delivery without an increased bandwidth requirement. In the priorart, there are two kinds of hybrid FEC and ARQ schemes. In a first kind,repair bits are sent within a repair packet to correct bit errors orerasures, unless the number of repair bits is large. In that case, aretransmission scheme is used. In a second kind, the repair bits aretransmitted separately from the data packets.

The protocols discussed above all operate in the IP layer. A link layerprotocol extends reliable multicast in multi-access wireless LANs at thelast hop of a wireless link, using both positive feedback (ACK) andnegative feedback (NACK) packets. Under this protocol, a receiver in themulticast group is chosen as a “leader” or representative for thepurpose of sending feedback to the sender (e.g., a base station).Whenever the leader successfully receives a packet, it returns an ACKpacket. However, if this leader node detects an error in the receiveddata packet, the leader node does not send an acknowledgement, therebytriggering an automatic retransmission from the sender. If anotherreceiver, not the leader, detects an error in its received packet, thisreceiver sends out a negative acknowledgement (NACK) packet, whichconflicts with the ACK packet sent from the leader. When such acondition occurs, the sender retransmits the packet.

IP layer multicast protocols typically include techniques formaintaining the multicast tree, estimating round-trip-time delay,managing group membership, and choosing error recovery methods. Theseprotocols are designed for complex network topologies in which sendersand receivers are interconnected with multi-hop links and have differentlink bandwidths, crossover traffic, and loss probabilities. For a simpletopology involving one sender and multiple receivers connected by singleshared wireless link, using such an IP layer multicast would beinefficient and overkill.

The article “Parity-based loss recovery for reliable multicasttransmission,” by J. Normenmacher, E. Biersack, and D. Towsley, IEEETran. on Networking, August 1998 describes a multicast scheme that (1)uses a stop-and-wait ARQ scheme to recover packet loss, (2) selects asingle receiver as a leader of the multicast group, and (3) treats acollision of an ACK packet and a NACK packet as a negativeacknowledgement. However, this stop-and-wait ARQ scheme is suitable onlyfor a 802.11 type network having a small bandwidth-delay product. For awireless network with a high bandwidth-delay product (e.g., a 802.20network), a stop-and-wait ARQ scheme is considered wastefull of channelbandwidth. Also, the single leader approach represents a single point ofpotential failure and requires some overhead for leader maintenance.Further, the NACK and ACK collision approach can be used only in systemwhere, at any given time, only one packet is outstanding and remains tobe acknowledged. Under such a scheme, the sender determines anunsuccessful transmission by detecting collision, without having toexamine the details of the acknowledgement received. However, ifmultiple packets can remain unacknowledged, the sender needs to examineeach acknowledgement to find out which packets among the outstandingones are lost. So the collision of ACK and NACK packets only signals theloss of some packet, unless further examination is carried out.

SUMMARY OF THE INVENTION

The present invention provides a scalable and reliable multicast methodin a wireless network with high bandwidth-delay product, using linklayer error detection and recovery techniques. The method is applicableto a method in which a sender at a base station and the receivers withinthe range of the base station are interconnected by wireless links witha high bandwidth-delay product. One applicable media access control(MAC) layer protocol for communication using these wireless links istime division multiplex access/time division duplex (TDMA/TDD).According to one embodiment of the present invention, a method of thepresent invention may combine FEC recovery, proactive protection,feedback suppression, NACK collision, and data and feedback grouping.

To fully utilize bandwidth, the method of the present invention maytransmit simultaneously a group of multicast packets from the basestation to a number of receivers. To suppress the number of feedbackpackets from all receivers, negative acknowledgement (NACK), instead ofaffirmative acknowledgement (ACK), is used to feed back to the sender.According to one embodiment, as both the receipt of a NACK packet andthe detection of a NACK packet collision are treated as incidents of aNACK packet, multiple receivers targeted by the multicast may beassigned to the same time slot.

In one embodiment, a FEC-based packet loss recovery technique uses thesame FEC packets to recover heterogeneous packet losses of differentreceivers. Given a large number of receivers with heterogeneous losspatterns, such a method greatly decreases packet retransmissions. FECpackets allow a NACK collision to be treated as the receipt of a NACKpacket, as there is no need for tracking sequence numbers. Accordingly,a method of the present invention is scalable.

To decrease the delay of packet transmission, one method of the presentinvention provides proactive protection at both sender and receiversides. At the sender side, FEC packets are sent with data packets. Atthe receiver side, recovery packets are requested in advance of actualpacket losses.

According to another embodiment of the present invention, to enhancescalability and reliability, group acknowledgement from differentreceivers is accomplished by assigning each feedback time slot to allreceivers of a predetermined number of packet losses. Under such ascheme, the feedback bandwidth required depends only on the number ofpackets sent, rather than the number of receivers in the system.Scalability is therefore achieved. At the same time, reliability isachieved because each receiver obtains all necessary FEC recoverypackets.

Thus, the present invention supports scalable and reliable multicastservice at the MAC layer. A method according to the present invention isespecially suitable for use in a wireless network with a highbandwidth-delay product, and thus are advantageous over the prior artIP-layer based methods, or other methods that are suitable only forwireless link with low bandwidth-delay product. Further, a methodaccording to the present invention may recover multicast packet losseslocally at the wireless hop. As packet corruption in the wireless linkis a significant cause of packet loss, a local recovery scheme allowsvery speedy recovery, relative to end-to-end based packet recoverymethods.

In addition, a method embodying the present invention in the wirelesshop can be combined with an IP-layer based multicast technique thatprovides reliable multicast in the core network. The present inventioncan save substantial wireless bandwidth, as compared to conventionalIP-layer based multicast techniques that use unicast connections betweenthe base station and each wireless terminal. A method using multicastreduces the congestion that results from the unicast traffic in thewireless links.

A method of the present invention is scalable because the number ofacknowledgement packets does not depend on the number of receivers. Bymultiplexing acknowledgement packets from different receivers to a smallnumber of time slots, and by treating a NACK collision event asequivalent to receiving a NACK packet, a method of the present inventioncan use the same number of uplink data channel and downlink data channeltime slots to realize a fully reliable multicast service. Such a methoddoes not require specific sequence numbers to keep track of NACKpackets, further enhancing the method's scalability to systems ofgreater complexity. Scalability also results from assigning allreceivers experiencing the same number of packet loss to the samenegative acknowledgement time slot.

A method of the present invention may use FEC parity packets to recoverpacket loss. In a system having a large number of receivers and aheterogeneous loss pattern, using FEC can substantially decrease thenumber of packet retransmission.

The present invention is better understood upon consideration of thedetailed description below and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the feedback implosion problem that plagues multicastprotocols of the prior art.

FIG. 2 shows system topology 200, in accordance with one embodiment ofthe present invention.

FIG. 3 illustrates a TDMA/TDD scheme 300, according to one embodiment ofthe present invention.

FIG. 4 is a block diagram showing functional blocks in the MAC layer andthe physical layer (PHY) of base station 201.

FIG. 5 is a block diagram showing functional blocks 500 in the MAC layerand the PHY layer of a multicast receiver, in accordance with oneembodiment of the present invention.

FIG. 6 illustrates scheduling of an uplink data channel and a downlinkdata channel, in accordance with one embodiment of the presentinvention.

FIG. 7 is detailed flow chart 700, showing the functions that arecarried out at a base station, in accordance with one embodiment thepresent invention.

FIG. 8 is detailed flow chart 800, showing the functions that arecarried out at a receiver, in accordance with one embodiment the presentinvention.

FIG. 9 is a flow chart illustrating the operations of error detectionblock 503 of FIG. 5.

FIG. 10 is a flow chart illustrating the feedback grouping mechanismpreviously described with respect to FIG. 6.

FIG. 11 is a flow chart illustrating the operations of a base stationwith respect to both receiving a NACK packets and handling a NACK packetcollision, in accordance with one embodiment of the present invention.

FIG. 12 is a flow chart illustrating the operations of FEC calculationblock 405 in the base station, in accordance with one embodiment of thepresent invention.

FIG. 13 shows a data format for a MAC layer data packet, in accordancewith one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a method for supporting scalable andreliable multicast in a wireless network with a high bandwidth-delayproduct. FIG. 2 shows system topology 200, in accordance with oneembodiment of the present invention. As shown in FIG. 2, base station201 is a multicast sender in cell 202 served by base station 201. Mobileterminals 1-3, which are each communicating with base station 201 bywireless links, are receivers in a multicast group. In this embodiment,the downlink (i.e., from base station 201 to mobile terminals 1 to 3)and the corresponding uplink (i.e., from the mobile terminals to basestation 201) are provided by multiplexing and duplexing thecommunication medium (e.g., a particular center frequency) in the mediaaccess (MAC) layer, using a time division multiple access/time duplexdivision (TDMA/TDD) scheme.

FIG. 3 illustrates a TDMA/TDD scheme 300, according to one embodiment ofthe present invention. As shown in FIG. 3, TDMA/TDD scheme 300 dividesthe available bandwidth into time periods 301-1, 301-2, . . . andallocates these time periods in an interleaved manner to transmissionsby the downlink (e.g., 301-1, 301-3, . . . ) and transmissions by theuplink (e.g., 301-2, 301-4, . . . ). Portions of both the downlinktransmissions and the uplink transmissions are dedicated totransmissions of data packets and thus are respectively referred to asthe “downlink data channel” and the “uplink data channel”. Each of thedata channels are divided into time slots. In each time slot, only oneuser, or one group of users, is allowed to transmit. The bandwidthsallocated to the data channels need not to be equal or fixed, and may,in fact, change from time to time. A dedicated control channel is usedby the base station to broadcast assignments of the time slots to theuplink and downlink data channels, such that each receiver is informedof the time slots in which it may transmit data or acknowledgementpackets to the base station, or receive data packets from the basestation designating it as a recipient. For example, as shown in FIG. 3,receivers in multicast group 1 and in multicast group 2 are eachassigned a group of four time slots, indicated by reference numerals 302and 303, respectively, in transmission time period 301-2. All receiversin the same multicast group uses the same uplink channel time slots totransmit acknowledgement, according to this embodiment of the presentinvention. FIG. 3 also illustrates the base station transmittingmessages 304-1, 304-2 and 304-3 during downlink transmission time period301-1. Each message may be a multicast message (e.g., a multicastmessage to multicast group 1 or multicast group 2, as shown in scheme300 of FIG. 3) or a unicast message, and may include multiple packets(e.g., message 304-1 includes the packets indicated by referencenumerals 303). The downlink transmission period may be allocated fortransmitting the messages in a multiplexed manner. Similarly, the uplinktransmission time period may be multiplexed for transmittingacknowledgement or data packets from different receivers or groups. Inthe following description, under a method of the present invention, atransmission period in the downlink data channel (e.g., transmissiontime period or “frame” 301-1) followed by a transmission time period inthe upline data channel (e.g., transmission time period 301-2) isreferred to as a “round”.

FIG. 4 is a block diagram showing functional blocks 400 in MAC layer 400a and physical layer (PHY) 400 b of base station 201. As shown in FIG.4, functional blocks 400 include MAC layer 400 a and PHY layer 400 b ofbase station 201. PHY layer 400 b includes transmitter 401, whichreceives MAC layer data units from channel assignment block 407 fortransmission over a wireless link. PHY layer 400 b also includesreceiver and collision detection block 402, which receives packets fromthe wireless link and uploads the received packets to error detectionblock 403. Receiver and collision detection block 402 also measures thesignal strength during the time slots used for multicastacknowledgement. In one embodiment, the TDMA/TDD scheme is NACK-based,and thus no ACK packet is transmitted for correct reception of datapackets. In that embodiment, multiple receivers may use the same timeslot for NACK packet transmission, and thus a collision detected in thattime slot represents multiple receivers each sending out a NACK packet.Receiver and collision detection block 402 differentiates between aquiet channel (i.e., no transmission) and reception of a NACK packet(i.e., either as a successful receipt of a single NACK packet, or asdetection of a packet collision condition) and reports the result to theerror detection block 403 of MAC layer 400 b.

Error detection block 403 provides verified data packets to output queue409 which, in turns, passes the data packets up the protocol stack forprocessing by a higher level protocol (e.g., an IP layer protocol). (Inthis description, a verified data packet is a data packet that isreceived without an error detected at the MAC and PHY protocol layers).Error detection block 403 also receives from receiver and collisionblock 402 the NACK packets received and the signals indicating acollision condition for the multicast traffic, and identifies the datapackets relating to the transmission failures. A number of errordetection and correction schemes can be used with the present invention.For example, in one embodiment, the sender sends FEC parity packets toreceivers which fail to correctly receive all the data packets of amulticast group, according to the multicast transmission schemedescribed below.

One suitable FEC algorithm is discussed in “Reliable broadbandcommunications using a burst erasure correcting code,” A. J. McAuley,published in SigComm90, September 1990. In that FEC algorithm, for a setof k data packets {p₁, p₂, . . . , p_(k)} to be encoded, Reed-Solomonerasure correcting code (“RSE code”) provides a set of n-k {d₁, d₂, . .. , d_(n-k)} parity packets. The RSE decoder at a receiver canreconstruct the k data packets {p₁, p₂, . . . , p_(k)} using any k outof the n data and parity packets {p₁, p₂, . . . , p_(k), d₁, d₂, . . . ,d_(n-k)}. Because a RSE encoder that operates on a large symbol size isdifficult to implement, MAC layer data packets are usually encoded usingmultiple m-bit encoders in parallel. In this algorithm, the total numberof data and parity packets, n, is only limited by the constraint:n≦2^(m). For example, using 16- or 32-bit symbols, up to 2¹⁶ or 2³²packets can be corrected. In practice, the total number of packets, n,and the number of FEC parity packets, n-k, can be selected to have anyvalue to accommodate the size of multicast group and the channel losscharacteristics. The description below illustrates the present inventionusing an error detection and correction mechanism, such as the RSEcorrecting code described above.

Thus, based on the number of packets reported lost in a current round,error detection block 403 determines the number of additional FEC paritypackets needed for transmission in the next round. Multicast Buffer 404stores the multicast group packets of the previous and current roundsand the FEC parity packets that have already been transmitted. Thesepackets are removed from multicast buffer 404 when error detection block403 indicates that no additional FEC parity packets are needed to betransmitted to the receivers. FEC parity packets that are needed arecomputed in FEC calculation block 405, using the multicast group packetsand the FEC parity packets already transmitted.

The FEC parity packets output from FEC calculation block 405 aremultiplexed with other data packets from multicast grouping block 406,and crossover traffic block 408 in channel assignment block 407.Crossover traffic block 408 manages all data packets not involved in themulticast described herein.

Under the MAC protocol TDMA/TDD, different data streams are assigneddifferent time slots by channel assignment block 407. The FEC paritypackets from FEC calculation block 405 are assigned a higher prioritythan new packets received from multicast grouping block 406, so as toallow rapid packet loss recovery. Generally, FEC parity packets from FECcalculation block 405 are assigned to time slots before any new datapacket from multicast grouping block 406 is assigned. Multicast groupingblock 406 buffers multicast packets from input queue 410 becausereliable multicast transmission often takes longer time than unicastpackets. Multicast grouping block 406's prevents blocking of input queue410 and allows FEC parity packets to be used in conjunction withmulticast data packets.

In this embodiment, proactive protection estimation block 411 calculatesthe current packet loss ratio based on the measurement in errordetection block 403. Using the current packet loss ratio, proactiveprotection estimation block 411 determines a proactive protection ratio,which is the ratio of proactive FEC parity packet packets relative todata packets. The proactive protection ratio is then used by FECcalculation block 405 to create FEC parity packets, which are thenprovided to channel assignment block 407 for proactive transmission. Theuse of proactive protection is optional.

FIG. 5 is a block diagram showing functional blocks 500 in the MAC andPHY layers 500 a and 500 b of a multicast receiver, in accordance withone embodiment of the present invention. As shown in FIG. 5, transmitter501 in MAC layer 500 b transmits both data packets and acknowledgementpackets. As mentioned above, time slot assignments of both the uplinkdata channel and the downlink data channel are received from the basestation (e.g., base station 201) through a dedicated control channel.Channel multiplexing block 507 multiplexes data packets for output tothe wireless link through transmitter 501 during the assigned uplinktime slots. At the assigned downlink time slots, receiver block 502receives data packets from the wireless link, provides verified packetsto error detection block 503, or reports to error detection block 503any physical layer error in the receipt packets. Error detection block503 stores verified multicast packets in multicast buffer 504, andreports the number of corrupt data packets received or detected in thecurrent round to acknowledgement block 506. Acknowledgement block 506provides a NACK packet to be transmitted in the uplink data channel atthe appropriate acknowledgement time slot.

In this embodiment, proactive protection block 510 performs functionssimilar to those described above for proactive protection block 411 ofbase station 201. Proactive protection block 510 calculates the currentloss percentage based on the error measurements from error detectionblock 503 and output a proactive protection ratio to acknowledgementblock 506. Proactive protection block 506 then provides NACK packetsbased on the product of the number of actual loss packets in the currentround and this proactive protection ratio. As in base station 201,proactive protection block 510 and its use are optional. Within thescope of the present invention, proactive protection may be used by thesender, the receiver, or both.

Multicast buffer 504 stores the verified data packets and the FEC paritydata packets of the multicast group received until the total number ofdata packets and FEC parity packets is sufficient to reconstruct themulticast group. At that point, the data packets and the FEC paritypackets, if any, are provided to FEC recovery block 505, which recoversthe data packets. The recovered data packets are placed in output queue508 to be passed up protocol stack for processing by a higher levelprotocol.

FIG. 6 illustrates scheduling of the uplink data channel and thedownlink data channel, in accordance with one embodiment of the presentinvention. As shown in FIG. 6, a multicast group of packets, includingpackets P₁, P₂, . . . , P₆, are shown transmitted downlink (designatinga multicast group address), and received by receivers 1, 2, and 3. Ofcourse, both the number of packets and the number of receivers shown inFIG. 6 are provided for illustrative purpose only. In practice, a muchgreater number of receivers and a much greater number of data packetsmay be accommodated within the scope of invention. In round 1 (i.e.,frames 602-1 and 602-2), four data packets (P₁, P₂, P₃, P₄) aretransmitted in the downlink data channel. (In this description, fourtime slots are provided in each time frame merely for illustrativepurpose; in practice, any number of time slots can be provided in eachtime frame) In FIG. 6, receiver 1 experiences errors in receiving datapackets P₂ and P₄, receiver 2 experiences an error in receiving datapacket P₃, and receiver 3 experiences an error in receiving data packetP₁. Thus, each receiver fails to receive at least one data packet whichis different from the data packets failed to be received by the otherreceivers.

According to the embodiment of the present invention illustrated in FIG.6, the number of assigned uplink acknowledgement time slots is equal tothe number of assigned downlink data transmission time slots. Therefore,four time slots (indicated by reference numeral 602-2) are assigned foracknowledgement of the data packets transmitted in the current round.Under this arrangement, the first time slot in frame 602-2 is assignedto all receivers which fail to receive all of the four packets P₁, P₂,P₃, P₄, the second time slot of frame 602-2 is assigned to all receiverswhich fail to receive three of the four packets P₁, P₂, P₃, P₄, thethird time slot of frame 602-2 is assigned to all receivers which failto receive two of the four packets P₁, P₂, P₃, P₄, and the fourth timeslot in frame 602-2 is assigned to all receivers which fail to receiveone of the four packets P₁, P₂, P₃, P₄. Thus, receiver 1 sends a NACKpacket during the third time slot (indicated by reference numeral L₂),and receivers 2 and 3 each send a NACK packet during the fourth timeslot (indicated by reference numeral L₁). With two transmitters at thefourth time slot of frame 602-2, a collision is detected at the basestation, which considers this collision condition to be the same ashaving received a NACK packet. As the largest number of packets lostexperienced in any receiver during the current round is two, the basestation computes and prepares for transmission two FEC parity packets F₁and F₂ for recovery of packets P₁, P₂, P₃, and P₄; F₁ and F₂ arenon-duplicate FEC parity packets not previously transmitted.

In round 2 (i.e., frames 602-3 and 602-4), FEC parity packets F₁ and F₂are transmitted in the first and second time slots, respectively. Datapackets P₅ and P₆ are transmitted in the third and fourth time slots. AsFEC parity packets F₁ and F₂ relate to data packet sent in the previousround, data packets P₅ and P₆ of the current round are acknowledgedseparately from FEC parity packets F₁ and F₂. Thus, FEC parity packetsF₁ and F₂ are acknowledged in the uplink data channel in the first andsecond time slots of frame 6024, and data packets P₅ and P₆ areacknowledged in the third and fourth time slots of frame 602-4.Therefore, receiver 2, which fails to receive data packet P₆, transmitsa NACK packet in the fourth time slot of frame 602-4; similarly,receiver 3, which fails to receive both data packet P₆ and P₆, transmitsa NACK packet in the third time slot of frame 602-4.

As the number of acknowledgement time slots does not depend on thenumber of active multicast receivers, and depends only on the number ofdownlink data packets transmitted, a method of the present invention isscalable with respect to any increase in the number of multicastreceivers. A method of the present invention also takes advantage of FECtechniques to ensure reliable data delivery. As compared to the priorart, which requires a time slot to be allocated to each receiver foreach data packet transmitted, a method of the present invention issignificantly more efficient in bandwidth. As shown in FIG. 6, using amethod of the present invention, only two FEC parity packets, ratherthan four in the prior art, need to be transmitted to achieve errorrecovery.

FIG. 6 does not illustrate use of the proactive protection schemesdiscussed above. If proactive protection is used, the numbers of uplinkand downlink slots may be different. For example, if the downlinkproactive ratio is 1.5, then for a transmission of four data packets, 6downlink time slots for the four data packets and two FEC parity packetsmay be used. In that example, the uplink data channel needs only fouracknowledgement time slots, unless uplink proactive protection is used.

FIGS. 7 and 8 are detailed flow charts 700 and 800, showing thefunctions described above that are carried out at a base station and areceiver, respectively. In FIG. 7, at step 701, the base station's MAClayer broadcasts the time slot allocation assignment for multicast inthe downlink data channel and the uplink data channel in a dedicatedcontrol channel. At step 702, the MAC layer of the base station examineswhether previous multicast transmissions are complete. If any previousmulticast transmission is incomplete, at step 703, the MAC layer of thebase station collects the reception information of the incompletetransmissions. For each incomplete transmission, the MAC layer of thebase station determines at step 704 the required FEC parity packets forerror recovery, which are then assigned at step 705 for transmission inthe available slots of the current frame in increasing multicast groupnumber. If there are still empty slots remaining in the current frameafter all FEC parity packets relating to previous incompletetransmissions are served, at step 707, the MAC layer of the base stationfetches new data packets of a new multicast message from an upper layerprotocol in the protocol stack. At step 708, the MAC layer of the basestation prepares the FEC parity packets and new data packets fortransmission at the appropriate time slots.

In FIG. 8, the MAC layer of a receiver receives the time slotassignments and group information of a multicast transmission in thedownlink data channel and the uplink data channel from dedicated controlchannel (step 801). At step 802, the MAC layer of the receiver receivesa multicast data packet of the current frame from its PHY layer. Usingthe group information, at step 803, the MAC layer of the receiver sortsthe data packets into their respective multicast groups. Some or alldata packets from any one of the groups may be lost in the communicationchannel. For each multicast group of data packets, the MAC layer of thereceiver counts, at step 804, the verified data packets andnon-duplicate FEC parity packets received in the current round, so as todetermine any additional data packets or FEC parity packets that shouldbe received in next round to allow the multicast group to be correctlydecoded. At step 805, the MAC layer of the receiver determines whetherthe required number of packets for correct decoding the multicast groupof packets have been received. If the required packets have beenreceived, at step 806, the MAC layer of the receiver decodes anddelivers the data packets up the protocol stack (step 808). However, ifat step 805 the MAC layer of the receiver determines that additionaldata packets or FEC parity packets are required for any multicast group,the MAC layer prepares, at step 807, a corresponding NACK packet. Afterall the NACK packets are prepared, at step 810, the MAC layer of thereceiver transmits the NACK packets in the appropriate time slots in theuplink data channel.

FIG. 9 is a flow chart illustrating the operations of error detectionblock 503 of FIG. 5. As mentioned above, error detection block 503tracks the verified data packets, and provides the appropriate NACKresponse to the sender. As shown in FIG. 9, error detection block 503receives verified packets from the PHY layer at step 901. As discussedabove, these packets may be data packets or FEC parity packets from oneor more rounds. Interference in the wireless channel may corrupt thepackets and prevents verification. The verified packets are sortedaccording to their respective multicast groups (step 903) and NACKpackets are transmitted at the designated time slots according to thegroup assignment information received from control channel at step 902.For each multicast group, error detection block 503 determines both thenumber of non-duplicate FEC parity packets received (step 905), if any,and the number of data packets that have not been properly received(step 906). At step 908, error detection block 503 determines the numberof additional packets needed in the next round; based on thisinformation, the appropriate NACK packets are provided to be transmittedat the designated time slots.

FIG. 10 is a flow chart for the multicast system illustrating thefeedback grouping mechanism previously described with respect to FIG. 6.As shown in FIG. 10, at step 1001, the downlink data channel and uplinkdata channel assignments and multicast packet group information arereceived from the dedicated control channel. To allow theacknowledgement packets to uniquely index the loss patterns, the groupinformation from the control channel includes the number of time slotsallocated to each multicast packet group. Of course, such informationmay also be disseminated in a different form, e.g., in packet headers.At step 1002, the received packets are sorted into respective multicastpacket groups and, at step 1003, the required FEC parity packets of eachmulticast packet group in the next round are determined using, forexample, the method described above with respect to FIG. 9. As describedabove, in one embodiment, the acknowledgement time slot assignment inthe uplink data channel follows the group allocation in the downlinkdata channel (step 1004). However, when proactive protection is used,the uplink data channel and downlink data channel time slot assignmentsmay be different. Irrespective of whether proactive protection is used,the number of time slots of each multicast packet group and theirallocation in the downlink data channel and the uplink data channel arespecified in the manner describe above with respect to step 1001. Foreach group of acknowledgement time slots corresponding to a multicastpacket group, at step 1005, the first time slot indicates that all thepackets of the current round are received corrupted, so that the samenumber of FEC parity packets as the data packets of this round isrequired in next round. At step 1006, each receiver determines whetherthe current time slot indicates its FEC parity packet requirements. Ifso, at step 1008, the receiver sends out a NACK packet. No transmissionis made at the other time slots for acknowledging the current multicastpacket group. In the present embodiment, as the position of theacknowledgement time slot indicates the number of corrupt packetsreceived (also equal to the number of FEC parity packets required, inone embodiment), a counter may be used to keep track of the time for aNACK packet, e.g. a counter can be decremented until the count in thecounter equals the number of corrupt packets received (steps 1010-1011).The current round concludes when the all multicast packet groups havebeen acknowledged (step 1012).

FIG. 11 is a flow chart illustrating the operations of a base stationwith respect to both receiving a NACK packets and handling a NACK packetcollision, in accordance with one embodiment of the present invention.At step 1101, the base station detects packet transmission of eachuplink data channel time slot. At step 1102, the base station determinesif the NACK packet received can be verified (i.e., without error). Ifso, at step 1104, the base station concludes proper receipt of a NACKpacket. Otherwise, at step 1103, the base station determines whether thereceived signal power exceeds a previously determined average noisepower threshold. If such a higher received signal power is detected, aNACK packet collision is deemed to have occurred, thus indicating morethan one receiver has experienced the number of corrupt data packetsindicated by the current time slot. With respect to the base station,the base station treats this signal condition to be the same as havingreceived a NACK packet in the current time slot. However, at step 1103,if the base station detects less signal power than the average noisepower threshold, no NACK packet is deemed received (i.e., a quietchannel). The absence of a NACK packet transmission in the current ttime slot conveys the same information as a verified ACK packet. Thus,at step 1105, the base station may output to a higher level protocol aresult conveying the information of a positive acknowledgement.

FIG. 12 is a flow chart illustrating the operations of FEC calculationblock 405 in the base station, in accordance with one embodiment of thepresent invention. As shown in FIG. 12, at step 1201, FEC calculationblock 405 receives a packet recovery requirement from multicast buffer404. As one or more groups of multicast packets may coexist at the sametime, the packet recovery requirement may also involve several multicastgroups. At step 1202, FEC calculation block 405 determines if allmulticast packet groups have been processed. If so, no FEC calculationis required. Otherwise, at step 1203, FEC calculation block 405 selectsa multicast packet group which transmission has not been completed. Inone embodiment, the multicast packet groups to be processed are selectedin chronological order, beginning with the multicast packet group thatbegan transmission earliest. At step 1204, FEC calculation block 405checks whether or not the required FEC parity packets of the selectedmulticast group have been computed. If the required FEC parity packetshave not been computed, FEC calculation block 405 gets data packets frommulticast buffer 404 at step 1208, to compute the FEC parity packets atstep 1209. FEC calculation block 405 may compute more FEC parity packetsthan are required in the current round, as FEC parity packets are alsovulnerable to corruption during transmission. The number of additionalFEC parity packets to compute depends on the total number of receiversand the current channel condition, and any algorithm for determiningsuch redundancy may be used within the scope of the present invention.At step 1210, FEC calculation block 405 then transmits the FEC paritypackets to the receivers. At steps 1204-1205, if the required FEC paritypackets have already been calculated, FEC calculation block 405 providesthe existing FEC parity packets to the receivers. Typically, FECcalculation block 405 transmits non-duplicate FEC parity packets (i.e.,FEC parity packets that have not been previously transmitted).Otherwise, at step 1206, if the number of non-duplicate FEC paritypackets is less than necessary to recover the packet loss, previouslytransmitted FEC parity packets may be sent at step 1207.

FIG. 13 shows a data format for MAC layer data packet 1300, inaccordance with one embodiment of the present invention. The formatshown in FIG. 13 illustrates the present invention in a non-systemspecific manner; in any real system, additional system-related fieldsmay be included. As shown in FIG. 13, the first two fields of datapacket 1300, labeled data fields 1301 a and 1301 b, are the destinationaddress and source address, respectively. For a downlink data channeltransmission, the destination address is the multicast group address andthe source address is the MAC address of the base station. For an uplinkdata channel, the destination address is also the multicast address, butthe source address is the MAC address of a receiver. Packet type field1302 differentiates between a data packet, an FEC parity packet, and aNACK packet. For a data packet type, the “sequence number” field (1303)contains the MAC sequence number of the multicast group. Each multicastgroup keeps tracks of a consecutive sequence number ranging from 0 to amaximum value. “Beginning Sequence Number” field 1304 a and “EndingSequence Number” field 1304 b are not used in for a data packet. Payloadfield 1305 may contain any number of data words.

In a FEC parity packet, “Sequence Number” field 1303 contains the MACFEC sequence number of the multicast group. (The MAC FEC sequence numberis different from the MAC packet sequence number in a data packet.) TheFEC sequence number may also be numbered consecutively from 0 to amaximum value. “Beginning Sequence Number” and “Ending Sequence Number”fields 1304 a and 1304 b of a FEC parity packet specify the beginningand ending MAC data packet sequence numbers that the FEC parity packetcorresponds.

In one embodiment, the sequence number fields 1303, 1304 a and 1304 bare not used, as the positions of the time slots indicate the number ofdata packets that are lost.

The above detailed description is provided merely to illustrate thespecific embodiments of the present invention and is not intended to belimiting its scope. Numerous variations and modifications within thescope of the invention are possible. For example, grouping theacknowledgement traffic from different receivers can be implemented inways different from those described above. In particular, if the uplinkdata channel time slots can be used as binary counters (i.e., the n-thtime slot may be used to indicate a 2^((n−1)) packet loss). In such ascheme, the number of uplink data channel time slots can be much lessthan the number of downlink data channel time slots. For example, everyseven downlink data channel time slots require only three uplink datachannel time slots. Such a scheme, of course, requires the receivers tobe able to monitor each other's transmission, and thus has a limitedapplication. Other encoding of uplink data channel time slots maysimilarly be provided.

In the above description, by treating a NACK collision as equivalent toreceiving a NACK packet, the need for an ACK packet is obviated. Toreliably detect a NACK collision, however, the system requires anability to distinguish between different levels of background signalvariation. Alternatively, one may implement both ACK and NACK schemes.To avoid collision of ACK packets, a receiver may be selected, perhapsrandomly, as the “leader” of the receivers, which is responsible forproviding an ACK packet in each uplink data channel time slot. At thesame time, each non-leader receiver transmits only NACK packets, in themanner described above. Under this scheme, if an error occurs, the NACKpacket and ACK packet would collide, resulting in a corruptedacknowledgement packet received at the sender. Thus, a properly receivedACK packet indicates that the corresponding data packet has beencorrectly received by all receivers, and a corrupted acknowledgementpacket indicates that at least one receiver fails to correctly receive apacket.

The present invention is set forth in the following claims:

1. A method for providing scalable reliable multicast service,comprising: transmitting a group of data packets over a communicationmedium to a group of receivers designated by a multicast address; andreceiving over the communication medium from the group of receiversacknowledgement packets, each acknowledgement packet representing afailure by one of the receivers to receive a number of the data packetsspecified by the acknowledgement packet; wherein the communicationmedium is multiplexed between a first data link for transmitting packetsto the receivers, and a second data link for receiving packets from thereceivers, the first data link and the second data link each beingprovided a time period for data transmission of a predetermined durationbefore yielding the communication medium to the other data link.
 2. Amethod as in claim 1, wherein the communication medium comprises a firstdata link for transmitting packets to the receivers, and a second datalink for receiving packets from the receivers.
 3. A method as in claim1, wherein the communication medium is divided into time slots andwherein, during receiving, each time slot is assigned to the receiversfor acknowledging a failure to receive a specified number of datapackets.
 4. A method as in claim 3, wherein the specified number of datapackets not received is implicitly specified by the position of eachtime slot.
 5. A method as in claim 4, wherein a collision detectedduring receiving in a time slot is deemed to be equivalent to receivingan acknowledgement packet in that time slot.
 6. A method as in claim 1,further comprising sending a control packet to the receivers specifyingan allocation of the communication medium for transmitting the datapackets and for the receivers to send the acknowledgement packets.
 7. Amethod as in claim 1, wherein the data packets include one or moreforward error correcting parity packet (FEC) prepared in response to anacknowledgement packet received.
 8. A method as in claim 7, wherein thenumber of FEC parity packets prepared corresponds to the largest numberof data packets failed to be received by a receiver, as indicated by theacknowledgement packets received.
 9. A method as in claim 7, furthercomprising storing the data packets and the FEC parity packets in amulticast buffer until a sufficient number of data packets and FECparity packets are deemed received by the receivers.
 10. A method as inclaim 1, further comprising transmitting one or more forward errorcorrecting parity packet (FEC) proactively in anticipation of failure bythe receivers to receive one or more of the data packets.
 11. A methodas in claim 1, wherein the data packets include data packets of aplurality of multicast messages.
 12. A method as in claim 1, whereineach time period is divided into a plurality of time slots.
 13. A methodas in claim 12, wherein the time slots in the first data link isallocated to the data packets of the multicast messages in a manner thatgives preference to multicast messages being submitted for transmissionat earlier times.
 14. A method as in claim 13, wherein the data packetsin one of the multicast messages comprise both data packets to betransmitted and forward error correction (FEC) parity packets.
 15. Amethod as in claim 14, further comprising determining the number of FECparity packets to be sent based upon the highest number of failures toreceive represented by the acknowledgement packets.
 16. A method as inclaim 1, further comprising receiving a positive acknowledgement packagefrom a selected one of the receivers.
 17. A method for providingscalable reliable multicast service, comprising: receiving a group ofdata packets transmitted by a sender over a communication medium, thedata packets being transmitted to a group of receivers designated by amulticast address; and transmitting over the communication medium anacknowledgement packet representing a failure to receive a number of thedata packets specified by the acknowledgement packet; wherein thecommunication medium is multiplexed between a first data link fortransmitting packets from the sender to the receivers, and a second datalink for transmitting packets from the receivers to the sender, thefirst data link and the second data link each being provided a timeperiod for data transmission of a predetermined duration before yieldingthe communication medium to the other data link.
 18. A method as inclaim 17, wherein the communication medium comprises a first data linkfor transmitting packets from the sender to the receivers, and a seconddata link for transmitting packets from the receivers to the sender. 19.A method as in claim 17, wherein the communication medium is dividedinto time slots and wherein each time slot allocated for transmitting anacknowledgement packet is shared by the receivers for acknowledging afailure to receive a specified number of data packets.
 20. A method asin claim 19, wherein the specified number of data packets not receivedis implicitly specified by the position of the time slot.
 21. A methodas in claim 20, wherein a collision detected by the sender during a timeslot in which an acknowledgement packet is transmitted is deemed to beequivalent to receiving an acknowledgement packet in that time slot. 22.A method as in claim 17, further comprising receiving a control packetfrom the sender specifying an allocation of the communication medium fortransmitting the data packets and for the receivers to send theacknowledgement packets.
 23. A method as in claim 17, wherein the datapackets include one or more forward error correcting parity packet (FEC)prepared in response to an acknowledgement packet received.
 24. A methodas in claim 23, wherein the number of FEC parity packets expected to bereceived corresponds to the largest number of data packets failed to bereceived by a receiver, as indicated by the acknowledgement packetsreceived.
 25. A method as in claim 23, further comprising storing thedata packets and the FEC parity packets received in a multicast bufferuntil a sufficient number of data packets and FEC parity packets arereceived.
 26. A method as in claim 17, further comprising transmittingan acknowledgement packet proactively in anticipation of failure toreceive one or more of the data packets.
 27. A method as in claim 17,wherein the data packets include data packets of a plurality ofmulticast messages.
 28. A method as in claim 17, wherein each timeperiod is divided into a plurality of time slots.
 29. A method as inclaim 28, wherein the time slots in the first data link is allocated tothe data packets of the multicast messages in a manner that givespreference to multicast messages being submitted for transmission bysender at earlier times.
 30. A method as in claim 29, wherein the datapackets in one of the multicast messages comprise both data packets tobe transmitted and forward error correction (FEC) parity packets.